Subject: Answers to HPR questions from DCL

From: "Ray Bird" <[email-masked]>
Date: Wed, 15 Jun 94 10:46:20 EDT

Here are some more good questions about HPR from DCL (Mathew Finlayson).
The answers are flagged with '***'.  The plan is to incorporate changes
necessitated by the answers to these (and previous) questions into the
HPR document scheduled to go AP at AIW6 (Oct. 94).  It will be distributed
several weeks prior to the meeting.  One thing the document will not
contain is the internal node structure for HPR and the associated protocol
boundaries.  Again, thanks (Mathew) for perceptive questions.

Ray Bird and Lap Huynh

Reuse of RTP Connections
========================

In the large diagrams (9-3, 10-2, 10-3 and 10-4) there are decision boxes (A
and B) which give guidance to when RTP connections can be reused and when
Route Setup has to be performed.

There seem to be a couple of possibilities missing from these boxes.

1) Decision box B (in all cases) doesn't take into account the possibility
   that a currently used ANR path may pass through a CNN. If this has happened
   (and the Route-setup required on path-switch bit was set), then a new
   route-setup must be performed (in order for a new route to be calculated
   through the sub-area network).
   *** Good point.  Will fix and distribute in the AP version of the HPR document.

2) There is no suggestion that HPR can decide to reuse an RTP connection
   after performing Route Setup. This would be desirable, since an HPR node
   may be forced to repeatedly carry out the same route-setup protocol for
   sessions with the same COS in a couple of cases:

   (a) In the case of an NN CP-LU to NN CP-LU session, DS will satisfy LOCATE
       requests internally from the topology information (without sending a
       LOCATE externally), and hence without receiving the NCE of the remote
       CP-LU.

   (b) In the case where a node is performing APPN-HPR boundary function,
       (diagram 10-3) but the received BIND request does not carry the NCE
       of the remote end.

   In both these cases, without the decision to reuse a connection after
   route-setup, multiple RTP connections will be set up to cover the same
   route with the same COS.
   *** Good point.  Will fix and distribute in the AP version of the HPR document.

ARB Flow/Congestion Control
===========================

A number of points which are unclear in this area.

(1) The specification doesn't seem to explain what variables should be taken
    into account when picking the burst-time for a connection. Indeed,
    none of the examples provided mentions burst-time (although one does refer
    to a burst size of 8000 bits).

    *** The burst-time (Bt) is set based on the current send rate (Rs) and
        the burst-size (Bs), Bt=Bs/Rs.  The burst-size is set to a common
        value used by all connections (4K bytes).

(2) Can you clarify how the length of an NLP should be defined for the
    purposes of ARB control? Should the length be that of the Data, that of
    the data plus the THDR or that of the Data, THDR and NHDR. If the latter,
    should the fact that the NHDR will shrink in size during the packet's
    journey through the network be considered.

    *** Only the data is considered for the purposes of ARB control.  Each
        time a packet is sent within a burst-time Bt, the burst-size Bs is
        reduced by the amount of data sent in the packet.

(3) The specification discusses at length how the Measurement interval, M,
    should be decided (section 7.2.4.4.6). The Formats at the end of the
    document (A.1.6.6) state that the Measurement Interval should always
    be set to 256 milliseconds. Which is accurate?

    *** The measurement interval is initially set to a value but is adapted
        to the roundtrip time (the roundtrip time is monitored by RTP)
        once the connection is active.

Bind Request
============

The specification refers to the NCE for the remote end being carried within
the BIND in the APPN-HPR boundary condition flow (figure 10-3). Unfortunately
the Formats section for the BIND (A.2.8) doesn't mention where the NCE ought
to be stored.
*** After reconsidering, this has been removed.  APPN nodes will not
    transfer the NCE from the search reply to the BIND.  Therefore, the
    NCE will never appear on the BIND.

Path Switch Controllers
=======================

The specification is slightly unclear regarding the definition of path switch
controllers. Is it valid for an implementation to allow this definition on
a per port (or even per link) basis?
*** Yes.  However, this capability was primarily intended for (future) mobile
    nodes and so generally is per node.  This type of node is moving so
    does not have wired links.

An example where this might be desirable would be a node with both wireless
and "wired" links. The specification seems to allow this possibility (since
the controller status is communicated on the Route Information) but there
seems to be a danger this would impact the path switch FSM (if the local node
changed from being passive to active during a path switch).
*** The controller status is established at RTP connection activation time.
    and remains that way for the life of the RTP connection.

Another problem is in the pseudo code in section 9.6.10 which contains the
logic for generating a new route. The code contains the line:

>     If the partner node is mobile then

without defining what is meant by mobile. Should it be replaced by

>     If the partner node is a path switch controller then

or is there another meaning?

*** It should read 'If partner RTP end point is path switch controller'.

Configurable Parameters for SNA-Defined COS
===========================================

The specification suggests that an implementation might like to make the
following HPR parameters configurable on a per COS basis.

-   path switch timer
-   retry limit
-   liveness timer

The specification should define default settings for the SNA-defined Classes
of Services (#CONNECT, #BATCH, etc) - the defaults will probably not suffice
for such a motley collection of COS's.

*** The architecture recommends default values for each of the above but
    allows each value to be associated transmission priority (instead of
    COS).  Porducts may then choose the association and default values
    to best suit their needs.

Status
======

Reading the discussion of the SHORT_REQ timer in the RTP specification
(page 11-12), I am not sure what the correct behaviour should be if
Partner-A decides that he must send (SR, RASAP) while (SR) is already
outstanding. This would occur, for example, if buffers became depleted
immediately after an ARB request had been sent.

*** If a (SR, RASAP) is necessary while (SR) is already outstanding,
    Partner-A will send the (SR, RASAP) and then it restarts the
    SHORT_REQ timer.  When an appropriate status segment (ST) is
    returned, the timer is cancelled.  The byte sequence number
    is used to time-stamp SR messages, only when a corresponding
    byte sequence number (or greater) is returned, the SHORT_REQ
    timer is cancelled.

Simply sending the (SR, RASAP) message would mean that the SHORT_REQ timer
would be stopped after the reply to the (SR) had been received. As far as
I can see, the best behaviour in this situation would be to initiate a
state-exchange. The incremented SYNC would mean the reply to the (SR) is
ignored.

*** The above scenario would ignore the reply ST to the earlier SR
    as well without doing a state-exchange.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================